The following abbreviations are defined as follows, at least some of which appear in the ensuing description:
DCHDedicated ChannelE-DCHEnhanced Uplink DCHHARQHybrid Automatic Repeat RequestHSUPAHigh Speed Uplink Packet AccessHWHardwareIEInformation ElementIubInterface between RNC and Node BIurLogical interface between two RNCsMACMedium Access ControlMAC-dMAC entity that handles dedicated transport channels (DCH)NBAPNode B Application PartNode BBase stationNSTNon-Scheduled TransmissionPDUProtocol Data UnitRLCRadio Link ControlRNCRadio Network ControllerRNSAPRadio Network Subsystem Application PartRRCRadio Resource ControlSHOSoft Hand OffSRNCServing Radio Network ControllerSTScheduled TransmissionUEUser Equipment, e.g., a mobile terminalUTRANUniversal Terrestrial Radio Access Network
Of interest herein is the HSUPA for packet data traffic in, for example, Release 6 of 3GPP TS 25.309, 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; FDD Enhanced Uplink; Overall Description; Stage 2.
In HSUPA, certain attempts at enhancements are currently approached by distributing some of the packet scheduler functionality to the set of Node Bs to provide faster scheduling of bursty, non-real-time traffic than can be provided by the Layer 3 (L3, Network Layer) of the RNC. The idea is that with faster link adaptation it is possible to more efficiently share the uplink power resource between packet data users, as when packets have been transmitted from one user the scheduled resource can be made available immediately to another user. This technique attempts to avoid the peaked variability of noise rise, such as when high data rates are being allocated to users that are running bursty, high data-rate applications.
In the current architecture, the packet scheduler is located in the RNC and therefore is limited in its ability to adapt to the instantaneous traffic, because of bandwidth constraints on the RRC signaling interface between the RNC and the UE. Hence, to accommodate the variability, the packet scheduler must be conservative in allocating uplink power to take into account the influence from inactive users in the following scheduling period, a solution which turns out to be spectrally inefficient for high allocated data-rates and long release timer values.
As general background, current HARQ process management for NST in 3GPP TS 25.309, v6.3.0 (2005-06), FDD Enhanced Uplink Overall Description Stage 2, for 2 ms TTI is as follows:                The UTRAN can restrict a non-scheduled MAC-d flow to use a limited number of H-ARQ processes, i.e.: a HARQ process that is “NST restricted” can be used by NST and ST; and when the UE has a set of “NST restricted” HARQ processes, processes that are not in this set cannot be used by NST, i.e. they can only be used by ST.        The UTRAN can reserve some HARQ processes for NST, i.e.: a HARQ process that is “NST reserved” can only be used by NST; and a H-ARQ process that is not “NST reserved” can be used by NST and ST. “NST restricted” and “NST reserved” can also be applied to H-ARQ processes on the same UE, or to the same H-ARQ process, e.g.: H-ARQ processes that are both “NST reserved” and “NST restricted” can only be used by NST.        
Of most interest to this invention is a determination as to which node should be responsible for reserving the HARQ process for 2 ms NST for the UE, the SRNC or the Node B (e.g., the serving Node B).
Arguments to support the SRNC controlling the HARQ process are that the SRNC is better positioned to calculate the number of processes which are required for the NST, and that Iub/Iur signaling is simpler to implement, and results in fewer delays. An argument to support the Node B controlling the HARQ process is that the Node B has the best knowledge of available HW resources and similar local issues.
However, a problem arises in the second approach since there is no means for the Node B, after reserving a HARQ process, to re-allocate the HARQ process except when the Node B receives a NBAP/RNSAP message with a request to execute a serving cell change, or to add new NST connection, for example, from the SRNC. Because of these limitations, the Node B cannot be expected to manage the HW resources in an efficient manner.